DevOps Overview BTech CSE Sem V · UPES Dehradun
Unit I · Lecture 1

The Advent of Software Engineering
& the Waterfall Method

From artisanal code to structured process —
how the software industry learned to build at scale.

COURSE
DevOps Overview
UNIT
I of IV
LECTURE
1 of series

Dr. Mohsin Furkh Dar  ·  School of Computer Science, UPES Dehradun

Overview

What We Cover Today

🕰️
Pre-Engineering Era
How software was built before formal methods existed.
⚠️
Software Crisis
Why 1960s projects collapsed and what it revealed.
🏛️
NATO Conference 1968
Birth of "Software Engineering" as a discipline.
💧
Waterfall Model
Sequential, phase-gated development explained.
🔍
Strengths & Limits
Where Waterfall works well — and where it breaks down.
🔗
Bridge to DevOps
Why these lessons motivate modern DevOps thinking.
Historical Context

Software Before "Engineering"

1940s
First electronic computers
1950s
Assembly & early languages
1960s
Crisis point reached
  • Craft-based development: Software was written by mathematicians and scientists — no formal process, documentation, or team coordination.
  • Hardware focus: Computers were rare and expensive. Software was treated as a secondary, easy problem — "just programming."
  • Individual heroics: Projects depended on the knowledge of one or two brilliant individuals. No knowledge transfer, no repeatability.
  • Scaling problem: As computers became cheaper and uses grew (payroll, defense, banking), programs grew far more complex than any individual could manage alone.
  • No version control, no testing discipline: Bugs were fixed ad-hoc. There was no concept of software "quality assurance."
The Problem

The Software Crisis of the 1960s

"The gap between expectations and reality for software projects was enormous. Projects ran over budget, over schedule, and delivered software that was unreliable — or simply never delivered at all."

Symptoms of the Crisis

  • Projects delivered years late
  • Cost overruns of 2–10×
  • Delivered systems failed in production
  • Requirements misunderstood or ignored
  • No way to measure progress reliably
  • Maintenance costs spiralling out of control

Root Causes Identified

  • No standardised development process
  • No formal requirement capture
  • Poor estimation techniques
  • Lack of modular design thinking
  • Communication failures between teams
  • Hardware complexity outpacing software practice
Famous failures: IBM OS/360 (1964), SAGE defense system cost overruns, Multics delays
Turning Point

NATO Conference 1968 — A Discipline is Born

50
Scientists & experts
Held in Garmisch, Germany — the first conference to formally address software development as an engineering discipline. The term "Software Engineering" was coined here deliberately to provoke — implying that software needed the rigour, discipline, and systematic approaches of traditional engineering fields.
01
Principles
Apply engineering rigour — specification, design, testing, and maintenance — to software construction.
02
Process
Development must follow repeatable, documented processes — not improvised each time.
03
Measurement
Progress, quality, and cost must be measurable. "Done" needs a clear definition.
04
Teamwork
Large software needs coordinated teams with defined roles — not lone heroes.
02

The Waterfall Model

Sequential, phase-gated software development
from Winston W. Royce (1970)

Waterfall Model

Sequential Development — The Core Idea

Winston W. Royce, 1970 — "Managing the Development of Large Software Systems"
Proposed that software development should proceed linearly through well-defined phases, each completed before the next begins.
Requirements
Requirements
System Design
System Design
Implementation
Implementation
Testing
Testing
Deployment
Deployment
Maintenance
Maintenance
← Each phase must be fully completed and signed off before the next begins. Flow is (ideally) one-directional.
Waterfall Model

The Six Phases — What Happens in Each

1
Requirements
All system requirements captured upfront in a Software Requirements Specification (SRS) document. No development begins without sign-off.
2
System Design
Architecture decisions made: hardware config, data structures, modules, interfaces, and algorithms. High-Level Design (HLD) + Low-Level Design (LLD).
3
Implementation
Developers write code based on the design document. Units are built and tested individually (unit testing).
4
Testing
The complete system is tested for defects: integration testing, system testing, UAT. Bugs found → fixed → re-tested.
5
Deployment
The finished, tested product is released to the production environment. User training may occur here.
6
Maintenance
Post-release bug fixes, performance patches, and feature enhancements. Longest and costliest phase in practice.
Waterfall — Evaluation

Where Waterfall Works Well

✅ Clear Structure
Every phase has defined deliverables, milestones, and entry/exit criteria. Easy for managers to track progress.
✅ Rich Documentation
Extensive docs produced at each phase — valuable for government contracts, compliance, and team onboarding.
✅ Stable Requirements
Works best when what needs to be built is fully understood upfront — e.g., embedded systems, space software.
✅ Easy Estimation
Sequential phases allow reasonably accurate time and cost estimates at project start.
✅ Team Specialisation
Analysts, designers, coders, and testers work in sequence — teams can specialise without overlap.
✅ Client Agreement
Contract-friendly: requirements are locked before work begins, limiting scope creep disputes.
Waterfall — Critical Limits

Why Waterfall Fails in Practice

Inflexibility to Change

  • Requirements locked at the start — any change is expensive
  • Going back to a previous phase is formally penalised
  • Real-world requirements always evolve — markets shift, users change their minds

Late Customer Feedback

  • Customer sees working software only at the end — after years
  • "Wrong product" discovered too late to fix cheaply
  • No mechanism for mid-course correction

Risk Accumulation

  • High-risk decisions made early with the least information
  • Integration problems surface only in the testing phase
  • Bugs found late cost 10–100× more to fix than if found early

Documentation vs Reality

  • Heavy docs become outdated the moment code changes
  • Teams optimise for phase sign-off, not working software
  • Testing is compressed when earlier phases run over
Standish Group CHAOS Report: 70%+ of Waterfall projects exceeded budget, schedule, or delivered incomplete functionality.
Summary

Waterfall at a Glance

Dimension Waterfall Approach Implication
Requirements Fixed upfront, fully specified Risk Cannot easily accommodate change
Progress visibility By phase completion, not working code Risk Stakeholders see value only at end
Testing After all code is written High risk Late bug discovery is costly
Documentation Extensive at every phase Strength Good for regulated industries
Best fit Stable, well-understood domains Strength Defense, aerospace, civil works
Failure mode Delivering the wrong product High risk Motivates Agile & DevOps
Royce himself noted in 1970 that a purely sequential model was inherently risky — he recommended iteration. This was largely ignored for two decades.
Lecture Wrap-Up

Key Takeaways & What's Next

💡
Origin
Software Engineering emerged as a discipline in 1968 because the craft-based approach could not scale — the crisis was real and widespread.
💡
Waterfall
Brought order and documentation to chaos. A major step forward — but assumed requirements are knowable, stable, and fixed. Rarely true.
💡
Late feedback
The core failure: customers see working software only at the end. By then, it is too expensive to change. This is the wound Agile addresses.
💡
Not dead
Waterfall still applies in domains where requirements are truly fixed: hardware firmware, medical devices, aerospace. Know when to use which.
➡️
Next lecture
Developers vs IT Operations conflict, the Agile movement (2001), and how the Agile Manifesto responded to exactly the problems we saw today.
DevOps Overview · Unit I · Lecture 1  ·  Dr. Mohsin Furkh Dar  ·  UPES Dehradun · Summer 2026
← → or swipe